Domain names are used to identify one or more Internet Protocol (IP addresses). Each domain name includes one or more characters (labels), each of which may either be an ASCII character or a language-specific character (e.g., Arabic, Chinese, Hindi, and Latin letters with diacritics (e.g., é)). Domain names represented, in whole or in part, by language-specific characters are called Internationalized Domain Names (IDNs).
In a domain name, each label is separated by dots. The right-most label conveys the top-level domain (TLD), and each label to the left specifies a subdomain of the domain to the right. For example, in the domain name “sub.example.com,” “corn” is the TLD, “example” is the second-level domain, and “sub” is the third-level domain. Examples of well-known TLDs include “.com,” “.net,” and “.org.” While not yet available, potential IDN versions of these well-known TLDs could also be created (e.g.  as unicode label and “.xn-c2br7g” as punycode label for Hindi .net).
The responsibility for operating each TLD is delegated to a particular company or organization (“Registry”), such as VeriSign, by the Internet Corporation for Assigned Names and Numbers (ICANN). The Registry contracts with one or more ICANN-accredited Registrars, such as GoDaddy.com, to provide registration services for Internet end users (Registrants). For some TLDs (e.g., .com and .net) the Registry does not store any Registrant contact information. Instead, the Registry stores, among other things, basic domain information and the Registrar who registered the name. This is known as a “thin” registry. Accordingly, the Registry does not know the identity of the Registrant, and if that information is needed, the individual or organization seeking the information must contact the Registrar. Conversely, in a “thick” registry (e.g., .name and .org), the Registry stores much of the information associated with the domain name, including the Registrant contact information. Since the new TLDs are required to support RFC 5733 “EPP Contact Mapping,” future IDN versions of TLDs such as .com and .net would need to support thick data.
Generally, the process for registering a domain name with a TLD begins when an Internet end user contacts a Registrar requesting to register a particular domain name. For example, Acme Corporation wishes to register the domain name “Acme.net.” The Registrar may then determine if “Acme.net” is available by checking one or more databases associated with the .net TLD. If the domain name is available, Acme Corporation may then proceed with the registration process of “Acme.net.” However, since the Registrar only checks a single TLD Registry, another Internet end user can register the same second-level domain label across a different TLD. For example, Beta Corporation could register “Acme.com.” Additionally, even if Acme Corporation was proactive in protecting its IP and registered Acme across all available TLDs at the time of registration, with the introduction of new TLDs, including IDN TLDs, Acme's IP rights could still be infringed at a later date. Thus, Registrars need to be capable of connecting efficiently with each Registry operating related TLDs to determine the availability of each related namespace. Accordingly, consistency across all commands that can change the sponsorship of a domain is needed. In particular, consistency may need to be validated for domain creates, domain updates since Registrants cannot be changed, and domain transfers where the Registrar can be changed.